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of the distributed database and 
makes the distribution transparent 
to users. We use the term distribut¬ 
ed database system to refer to the 
combination of the distributed data¬ 
base and the distributed DBMS. The 
following assumptions about the 
system underlie these definitions: 

□ Data is stored at a number 
of sites. Each site is assumed to 
consist logically of a single proces¬ 
sor. Even if some sites are multi¬ 
processor machines, the distribut¬ 
ed DBMS is not concerned with 
the storage and management of 
data on these machines. 

□ The processors at sites are 
interconnected by a computer net¬ 
work rather than a multiprocessor 
configuration. The important point 
here is the loose interconnection 
of processors that have their own 
operating systems and operate in¬ 
dependently. Although "shared- 
nothing" multiprocessor architectures 
are similar to loosely interconnect¬ 
ed distributed systems, they in¬ 
volve different issues (such as task 
allocation and migration and load 
balancing) that are not considered 
in this article. 

□ The distributed database is 
indeed a database, not a collection 
of files that can be stored individ¬ 
ually at each network node. This 
aspect marks a distinction between 
a distributed database and a dis- 
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tributed file system. To form a dis¬ 
tributed database, distributed data 
should be logically related accord¬ 
ing to some structural formalism, 
and access to data should be at a 
high level via a common interface. 
The typical formalism establishing 
the logical relationship is the rela¬ 
tional model. In fact, most research 
on distributed database systems as¬ 
sumes a relational system. 

□ The system has the full 
functionality of a DBMS. It is nei¬ 
ther a distributed file system nor a 
transaction-processing system. Trans¬ 
action processing is not only one 
type of distributed application, but 
it is also among the functions pro¬ 
vided by a distributed DBMS. How¬ 
ever, a distributed DBMS provides 
other functions, such as query pro¬ 
cessing and structured data organi¬ 
zation, which transaction-processing 
systems do not necessarily support. 

These assumptions are valid 
in today's technology base. Most 
current distributed systems are built 
on local area networks where each 


site is a single computer. The data¬ 
base is distributed so that each site 
manages a single local database (see 
Figure 1). Next-generation distribut¬ 
ed DBMSs will be designed differ¬ 
ently, however, as a result of tech¬ 
nological developments —especially 
the emergence of affordable multi¬ 
processors and high-speed net¬ 
works. System design will also be 
affected by the increasing use of 
database technology in application 
domains that are more complex 
than business data processing and 
by the wider adoption of the 
client/server mode of computing, 
accompanied by the standardiza¬ 
tion of the client/server interface. 
Thus, the distributed DBMS envi¬ 
ronment will include multiproces¬ 
sor database servers connected to 
high-speed networks linking them 
and other data repositories to cli¬ 
ent machines that run application 
code and participate in executing 
database requests. Distributed rela¬ 
tional DBMSs of this type are al¬ 
ready appearing, and several exist¬ 
ing object-oriented systems also fit 
this description. 

A distributed DBMS as defined 
here is only one way of providing 
database management support for 
a distributed computing environ¬ 
ment. We have devised a working 
classification of possible design al¬ 
ternatives along three dimensions: 4 

□ Autonomy refers to control 
distribution and indicates the degree 
to which individual DBMSs can 
operate independently. It involves 
a number of factors, including 
whether the component systems ex¬ 
change information, whether they 
can independently execute transac¬ 
tions, and whether a user is allowed 
to modify them. (In this context, 
"exchange information" does not 
refer to networking concerns but to 
whether the DBMSs are designed to 
exchange information and coordi¬ 
nate their actions in executing user 
requests.) Three types of autonomy 
are tight integration, semiauton¬ 
omy, and full autonomy. In tightly 
integrated systems, a single image 
of the entire database is available to 
users who want to share the infor¬ 
mation in multiple databases. Se- 
miautonomous systems consist of 
DBMSs that can (and usually do) 
operate independently but have 
been designed to participate in a 
federation to make their local data 
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